Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d8/pclablan.arc/README.TXT

Text File | 1988-05-14 | 19KB | 400 lines

«MDNM»Introduction
PC Magazine LAN Benchmark README.TXT File
------------

The PC Magazine LAN benchmark program is used to evaluate LAN
hardware and software.  This file provides an overview of the
test programs and instructions on how to use them.  The following
sections are included in this document:

        LAN Test Overview
        How to Run the Tests
        Cleaning Up and Filenames
        PC Labs Setup
        How We Interpret Results

You can write or call PC Labs at [phone] if you have
comments, suggestions, or questions.



LAN Test Overview
-----------------
The PC Magazine LAN benchmark test provides a way to impose a
consistent load on a LAN and to time specific procedures.  The
tests generate repeatable results, which can then be compared
with other similarly configured LANs with the same number of
workstations.

The following captions are printed in PC Magazine when LAN test
results are reported.  They provide an overview of the three
types of file loading used in the tests.

The PC Labs LAN benchmark tests are written in C and are
independent of commercial software.  We ran the tests on a test-
bed of five 8-MHz IBM PC ATs.  For our test-bed to better
simulate the conditions on a medium-size network of 20 or more
workstations, we have designed these loading tests so that a
single station represents five to ten times the load of a user
performing an interactive task (for example, updating records) on
a network.

By themselves, the elapsed times reported in these tests are not
meaningful.  They are valuable only when used to compare the
performances of two or more systems running under near-identical
conditions.  Accordingly, we include the tests run on our
Editor's Choice configuration of a 3Com 3Server3, 3+Share
software, and EtherLink interface cards to provide a point of
comparison.  We also show results from a network of Novell's
Advanced NetWare/286, EtherLink cards, and an IBM PC AT as the
server.  Advanced NetWare is our Editor's Choice for networking
software, and our tested configuration is a typical one.  The
times are in seconds.


  Network Speed Under Load Results

    Stations   3+Share    Advanced Netware/286
    --------   -------    --------------------
       0        306            264
       1        423            280
       2        529            301
       3        651            310
       4        761            322


  Hard Disk Access Load Results

    Stations   3+Share    Advanced Netware/286
    --------   -------    --------------------
       0        155            136
       1        227            150
       2        330            162
       3        419            174
       4        522            182


  Database Load Results

    Stations   3+Share    Advanced Netware/286
    --------   -------    --------------------
       0        155            136
       1        298            169
       2        425            212
       3        585            280
       4        669            305


The Network Speed Under Load and the Hard Disk Access Load
benchmark tests measure the time needed to perform a standardized
task on the network.  While the actual work loads used for these
two tests (described below) are different, we used the same
procedure for both.  To obtain the elapsed times shown here, we
ran a benchmark program performing a sequential create, a
sequential read, a sequential write, a random read, and a random
write of a large file.  The record sizes used in these activities
systematically rotate between 16K, 4K, and 512 bytes.  The
numbers shown in the three-dimensional chart are the total time
necessary for all of these operations.  We ran the test on all
our ATs to load the network while timing just one of them.  We
then reduced the number of workstations one at a time to show the
effect of loading on the network.

The Network Speed Under Load test puts a heavy load on the
network interface (cards, media, and so forth) while placing a
minimal load on the hard disk by having each station continuously
read and write its own 1-byte data file, changing the data each
time.  For systems with disk caching, the load on the hard disk
is even smaller, since cached systems typically perform a disk
write but do not require a physical disk read.

The Hard Disk Access Load test heavily loads the hard disk and
disk-caching system.  To do this, each station randomly accesses
its own 100K data file using 1K records.  Data written to the
file is changed each time.  The random reads typically access
data outside the cache, which forces a disk read, as does any
write.

The Database Load test exercises the system's record-locking
support and the way it handles a number of random simultaneous
accesses to a common file.  This test times how fast each loading
station accesses a common database consisting of an index and a
data file.  Half the accesses are simple searches of the index
file and an accompanying access to a record in the data file.
One quarter of the accesses perform the same operation but also
lock the data record and update its contents.  The remaining
accesses update the index file and a data record.  The index file
is locked during every update and the DOS 3.1 RLOCK statement
prevents simultaneous index file updates.



How to Run the Tests
--------------------
The LAN benchmark program uses only DOS 3.x file handling
facilities and does not require LAN-specific support such as
NETBIOS support.  The test configuration requires at least one
file server, which can be dedicated or nondedicated.  The network
must also have one or more DOS workstations attached.

The network being tested should be set up and running according
to the vendor's specifications before the benchmark program is
run.  Each workstation involved in a test should be logged onto
the network, and the LAN benchmark program must be running on
each workstation.

Any network options related to file sharing that may be necessary
for running the benchmark program should be implemented before
the tests are run.  The DOS SHARE program is often required for
the database load procedure.  Also, some systems require special
attributes to be set for these files.  Check the corresponding
network documentation on file sharing for details.

The LAN benchmark program is menu driven but it does require some
manual coordination and setup.  These options are chosen using
the setup menu, which creates a setup file--PCMAGLAN.ARG.

The LAN benchmark setup program should be run first.  It is
available from the main menu of the LAN benchmark program.  You
can choose from among various testing parameters--such as the
file sizes to be used in a test.  The setup file should then be
saved.  A single setup file can be shared if the file is
available on a shared directory on the LAN or individual copies
can be used on each workstation.

Select a LAN load procedure on each workstation attached to the
network.  These workstations access data on the file server
attached to the network--and are the cause of the contention for
processing power.  Only one workstation runs a time procedure to
obtain the final numerical results.  Remember to start the load
procedures before starting the time procedure.

The timed test runs to completion and should not be interrupted.
It can be terminated using the Control-Break keys, but no results
will be saved and the test must be restarted completely.  The
load procedures can be incrementally started or stopped while the
timed test is running without having to restart each load
procedure from scratch.  It is more likely that you will manually
terminate the load procedures after each portion of the time test
is completed.  The load procedures are interrupted using the Esc
(escape) key and a prompt will allow the procedure to be
terminated or to continue.

The load procedures are options 1, 2, and 3 on the main menu.
Load procedures 1 and 2 use individual and unique files for each
workstation, and the files can be contained in different
directories on a shared hard disk.  The database load procedure
uses a common set of files for all load workstations.  The files
used by the load procedures must be contained on the same network
file server; otherwise, the load procedure may have little or no
effect on the timed results.

Load procedures 1 and 2 and the timed test automatically create
their work files and delete them before the procedures terminate.
Load 3, the database load, requires predefined data files that
are built using the B option on the main menu.  The size of these
data files is specified in the setup menu.  The size of the file
is specified in terms of levels where smaller numbers equal
smaller files.  The sizes grow exponentially with respect to the
number of levels.

The timed test is option T on the main menu.  It performs
standard file operations on a single file, including creating the
file as well as sequential and random reads and writes.  The file
and record sizes can be specified in the setup menu and the
numbers can have a trailing K or M for kilobytes or megabytes,
respectively.  Record sizes can be in bytes, although the file
size is rounded up to the nearest kilobyte.  Up to eight record
sizes can be listed and the record sizes are processed in the
order listed.  The test file is deleted after each record size is
used and a new file is created for each additional record size.

The program provides two result files.  One is suitable for
printing or incorporation into a document using most word
processors (PCMAGLAN.TXT).  The second is formatted for
spreadsheet programs that can read comma-separated variable (CSV)
format files (PCMAGLAN.CSV).  The numbers saved in the timed test
result files are identical; only the format is different.  The
LAN benchmark program will append new results to the end of the
files if they already exist.



Cleaning Up and Filenames
-------------------------

Normally the timed procedure and loading procedures delete any
files they create when the test is done.  The exceptions are the
files created for the database load procedure.  These files must
be deleted manually using the DOS DELETE or ERASE commands.

The names of the work files used by the LAN benchmark program can
be changed in the setup menu, but the defaults include:

        PCMAGLAN.IDX       database index file
        PCMAGLAN.DAT       database data file
        TMPXXXXX           temporary work file

The temporary work-file names actually have the XXXXX replaced by
a random number so that each file is unique.  The temporary work
files may be accidentally left on the disk if the network or
program is terminated improperly or prematurely aborted.
Temporary files will never be used again, so they can be deleted
at any time.  Although the database files can be easily
reconstructed using the LAN benchmark program, they should be
deleted only when they are no longer needed.

PCMAGLAN.ARG is a file created from the setup menu.  It contains
the user-defined options.  A single copy of PCMAGLAN.ARG can be
placed on a shared directory on the file server or each
workstation can have its own copy.  PCMAGLAN.ARG is loaded by
default when the program is started.  There is no way to change
the default filename.  However, if you want to rename the file in
order to save different setups, you can load it explicitly
through an option found in the main menu.  Different setup files
can be used to save different test parameters, different LAN
names, and different result-file names.

The setup file PCMAGLAN.ARG does not have to exist for the LAN
benchmark program to run.  Default values are used if there is no
file.

PCMAGLAN.TXT and PCMAGLAN.CSV are the default names for the
result files created by the time test.  These can be deleted if
the results are no longer needed or can be saved accordingly.

All filenames can contain drive designations and directory path
names.  This allows more flexible placement of the files and
allows results to be placed on a drive other than the one being
tested.

The LAN benchmark program traps some errors, but occasionally
"disk full" errors or LAN-related errors occur.  It is also
possible to corrupt the LAN benchmark database files.  The
program will detect and report on the latter.  It is best to
delete all temporary and database files and regenerate the
database if this occurs.  The results for any timed test should
be disregarded if these types of errors occur.

In general, the LAN benchmark program can be aborted using
Control-Break.  Reboot or power-down the workstation if the
program must be terminated and it does not respond to Control-
Break.

Be careful when editing and appending time test results.  Some
text editors place an end-of-file character at the end of a file.
This character is not visible when the file is typed or edited.
The time test appends data to the physical end-of-file, which may
appear after this character if the result files are edited and
saved.  The data will be in the file but will not be accessible
using this type of editor or via the DOS TYPE command.  Edit only
copies of files from the time test to prevent this problem from
occurring.  Also, look at the file size versus the amount of
information that is viewable to see if this is a problem you may
have encountered.

Cummulative time test results are appended to the end of a result
file, not the beginning.  This is a useful way of keeping the
results for different numbers of workstations and different kinds
of loads.


PC Labs Setup
-------------

The results printed by PC Magazine are obtained by repeating the
LAN benchmark test using different load procedures and different
numbers of load workstations.

PC Labs uses standard IBM PC AT computers running at 8 MHz.  Six
ATs are used as workstations and an additional AT is used if a
dedicated AT server is required.  The dedicated AT server is
augmented with 2MB of extended memory when it is used.  The other
workstations have no extended memory.

One AT is designated as the timed workstation while the others
are load workstations.  The PC Labs configuration is set up in a
single room so that each workstation is easily viewed at the same
time.

When PC Labs tests a non-IBM server, the vendor's server replaces
the AT.  Servers are tested as delivered.  The LAN is set up
based upon the vendor's documentation.  No tuning is done on the
server or the workstations other than what is specified in the
standard installation procedure.  All configurations are tested
using supplied service programs and normal DOS applications to
make sure the LAN is running properly before the LAN benchmark
program is run.

How We Interpret Results
------------------------
As described above, the benchmark-test results reported in PC
Magazine are generated on a standard network configuration.
Although you can test any LAN using the PC Labs benchmark
program, results obtained using a LAN configuration different
from the PC Labs standard configuration cannot be compared with
results printed in the magazine.  The LAN benchmark program tests
file-access performance only.  It does not test other aspects of
the network such as print spooling, electronic mail,
communications, or bridges.

The three different load tests come into play as more
workstations log onto the network.  These tests are designed to
place an unusually heavy and consistent load on the network.
Bear in mind that the number of workstations a network
configuration can support is normally much larger than the
standard PC Labs LAN test configuration.

The Network Speed Under Load test is designed to place a heavy
load on the network software and transport mechanism.  Each
workstation reads and writes a single-byte file.  This should
generate a minimum amount of disk traffic on the server.  In
fact, some servers with good buffering techniques will perform no
disk accesses until the tests are done.  On the other hand, the
test should generate a great deal of network traffic.  The
network adapter on the server can be kept at maximum load with a
sufficient number of workstations.

The Hard Disk Access Load test also generates a good deal of
network traffic, but it also performs a large number of disk
operations.  The size of the data files used can be specified and
should be larger than the amount of buffering available on the
hard disk.  The traffic is similar to that encountered when
copying large amounts of data or when running applications that
heavily access the file server's hard disk.

The Database Load test uses a common database, which is accessed
by each load workstation.  Record locking is used on the index
file and data file.  Access to the records is random with a
distribution of data record reads, data record updates, and index
record updates.  The load simulates a heavy access to a common
database.  This would be comparable to a significantly larger
number of workstations performing query operations to a common
database.  The locking procedures are similar but not identical
to many commercial network database products.  However, the test
is primarily designed to show how good or bad a network supports
simultaneous file access with record locking.  DOS 3.x file and
record locking are mandatory for this test.

The time test can be used in conjunction with any other load
procedures you create.  PC Labs tests only the same type of load
within individual tests for consistency and to simplify
interpretation of test results.  The change in the test results
shows how much variance may be observed on a heavily loaded or
heavily populated network.

The time test results can be interpreted in isolation based on
the nature of the tasks (i.e., network traffic vs. server disk
access).  Results can be compared on the same network with
varying numbers of workstations logged on (i.e., network
contention for the same task with three workstations as compared
with eight).  Or you can compare a similar number of workstations
using the same load but different network configurations (i.e.,
token-ring vs. star topology).

For example, while write operations normally take longer than
read operations, the factor will vary depending upon the network
configuration.  Likewise, you can isolate the effect of
additional buffers on the server, as well as the workstation, by
changing the setup options and rerunning the tests.